Flash memory is a non-volatile storage chip that is electrically erasable and programmable. Negated AND (NAND) type flash memories exist in a wide range of portable storage devices, such as memory cards and USB drives. In recent years, the cost of NAND flash has dropped enough to make solid state drives (SSD) a viable option as primary storage devices for computer systems, often as a replacement for conventional hard disks.
Compared with traditional hard disks, flash/SSD devices (hereinafter, also generally referred to as an “SSD” device) have superior I/O performance. In addition, the cost of SSD devices has been continuously decreasing. These two factors make it increasingly popular to use SSD devices as a “second-level” cache which resides between the main memory (e.g., RAM) and a primary persistent storage such as a hard disk (as opposed to “first-level” or buffer cache which needs to utilize a portion of the main memory). Such a “second level” cache can be used by an operating system to cache “hot” I/O blocks (e.g., I/O blocks that may be frequently accessed) to improve I/O latency and throughput. Typically, such second-level caching involves a filter driver in the OS kernel I/O stack, which can intercept all I/Os, identify hot blocks, and dispatch I/Os to a cache or persistent storage.
In a virtualized environment, however, using a SSD device as a second-level cache brings up new challenges. For example, because a host computer system (e.g., a “host”) supports the running of multiple virtual machines (VMs) in a virtualization environment, the host computer system would need to manage the second-level cache on a per-VM basis and maintain VM-specific caching policies. One way to facilitate such “VM-granular” second-level caching might be to implement the second-level caching in the guest operating system (OS) that runs within a VM. However, implementing a second level cache within a guest OS may require significant modifications or additions to both (i) the virtualization layer of the host computer system that supports VMs (also known as a hypervisor), in order to expose at least a portion of the SSD device as a “virtual storage device” to the guest OS of VMs, and (ii) the guest OS (or applications running on top of the guest OS) within the VM, so that such guest OS or application is programmed or otherwise configured to actually utilize such a virtual storage device as a second level cache. Furthermore, dynamically sharing the SSD device in a host computer system among multiple VMs is also difficult.